Open question: should validation fail if both overrides & regular clevis configuration options are specified? I'm leaning towards yes but wanted to ask. Conflicting configs can be written otherwise e.x.:

"clevis": {
    "tpm2": true,
    "threshold": 1,
    "override": {
        "pin": "tang",
        "config": "{\"url\": \"http://my.tang.server:8443\", \"thp\": \"ABCDEF123\"}",
        "netdev": true
    }
}

Hmm, I wonder if we should reframe #1019 as support for "custom" pins instead? So e.g.

"luks": [
    {
        "name": "luksroot",
        "device": "/dev/md/foobar",
        "clevis": {
            "tpm2": true,
            "custom": {
                "pin": "my-custom-pin",
                "config": "{\"custom-field\": \"custom-value\"}"
            }
        },
        "label": "root"
    }
],

would use sss with both tpm2 and my-custom-pin.

One thing we could do down the road then is that if threshold is 1 (or omitted) and there is only one pin type given, we don't use sss and just use the one pin directly. That way custom would effectively have full control over the inputs, instead of being nested within the "sss wrapper".

/cc @puiterwijk -- this is about the comment you initially raised here.

Hmm, I wonder if we should reframe #1019 as support for "custom" pins instead?

My personal (slight) leaning would be to keep it as a complete override.

My personal (slight) leaning would be to keep it as a complete override.

Sure, I also see the appeal in that. The reason I suggested it was so that users could still leverage Ignition's built-in tpm2 and tang support (and the validation that comes with that) and minimize the JSON in string in JSON bit.

In that case yes, I agree we should make it an error if any other pinning options are specified. (Though small bikeshed: I'd still call it e.g. custom instead of override since the latter slightly implies to me that it's legal to have it alongside e.g. tpm2 and tang and those will just be ignored.)

I've written up a few different potential paths, do either of 2 or 3 encapsulate your proposal?

1. Complete override of the PIN & CFG (as is done in the current PR)

   • This is definitely the most straight forward approach code wise as we're just accepting string values and directly passing them to clevis
   • One drawback for this is that it makes the Ignition config potentially murky to read as even if other clevis fields are specified they are ignored

2. A custom object that overrides individual CFGs for a given PIN

   • This would directly override Tang sections rather than appending & when an SSS config is given it will entirely override the config

3. A custom list of objects that overrides TPM2 section, appends to Tang section, and merges the SSS CFG with the other custom objects & Ignition attrs

   • This might require Ignition to gain a greater understanding of all PIN CFG options to be able to properly merge SSS CFGs

Sorry for the delay on this.

I think just going with what you have here works. Two things:

• I agree we should error out if tpm2 or tang is specified.
• I think the key should be named e.g. custom instead of override. In my mind, override implies that tpm2 and tang are still allowed but just ignored. But it's clearer to say to users: "you can set up TPM2 and/or Tang or a completely custom config".

I agree we should error out if tpm2 or tang is specified.

If they're specified inside the config or if they're specified as the custom pin?

I agree we should error out if tpm2 or tang is specified.

If they're specified inside the config or if they're specified as the custom pin?

The former. In a custom pin users can then just do whatever they want.

Ok, this is rebased, updated, and tested. Should be good for review.

Updated.

Updated the error messages. Merging on green.